Professional Documents
Culture Documents
Step-by-step installation
instructions for IBM WebSphere
Portal
Implement new and enhanced
capabilities of IBM WebSphere
Portal
Rufus Credle
Denise Hendriks Hatzidakis
Sunil Hiranniah
Gord Niguma
Dwight Norwood
Roshan Rao
Bernhard Stimpfle
ibm.com/redbooks
International Technical Support Organization
February 2003
SG24-6920-00
Note: Before using this information and the product it supports, read the information in
“Notices” on page vii.
This edition applies to IBM WebSphere Application Server Advanced Edition V4.0.2, IBM
SecurewayDirectory V3.2.2, IBM WebSphere Personalization V4.0, DB2 Universal Database
V7.2, IBM WebSphere Studio Application Developer V4.02, and IBM WebSphere Portal for
Multiplatform V4.1.2.
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
The team that wrote this redbook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Comments welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Contents v
vi IBM WebSphere Portal V4.1 Handbook Volume 2
Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area.
Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product, program, or service that
does not infringe any IBM intellectual property right may be used instead. However, it is the user's
responsibility to evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document.
The furnishing of this document does not give you any license to these patents. You can send license
inquiries, in writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such
provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION
PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer
of express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may
make improvements and/or changes in the product(s) and/or the program(s) described in this publication at
any time without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the
materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without
incurring any obligation to you.
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm
the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on
the capabilities of non-IBM products should be addressed to the suppliers of those products.
This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrates programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the
sample programs are written. These examples have not been thoroughly tested under all conditions. IBM,
therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy,
modify, and distribute these sample programs in any form without payment to IBM for the purposes of
developing, using, marketing, or distributing application programs conforming to IBM's application
programming interfaces.
ActionMedia, LANDesk, MMX, Pentium and ProShare are trademarks of Intel Corporation in the United
States, other countries, or both.
Microsoft, Windows, Windows NT, Windows 2000 and the Windows logo are trademarks of Microsoft
Corporation in the United States, other countries, or both.
Red Hat, the Red Hat "Shadow Man" logo, RPM, Maximum RPM, the RPM logo, Linux Library, PowerTools,
Linux Undercover, RHmember, RHmember More, Rough Cuts, Rawhide and all Red Hat-based trademarks
and logos are trademarks or registered trademarks of Red Hat, Inc. in the United States and other countries.
Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun
Microsystems, Inc. in the United States, other countries, or both.
C-bus is a trademark of Corollary, Inc. in the United States, other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other countries.
SET, SET Secure Electronic Transaction, and the SET Logo are trademarks owned by SET Secure
Electronic Transaction LLC.
Other company, product, and service names may be trademarks or service marks of others.
These IBM Redbooks position the IBM WebSphere Portal for Multiplatforms as a
solution that provides a single point of interaction with dynamic information,
applications, processes and people to help build successful
business-to-employee (B2E), business-to-business (B2B),
business-to-consumer (B2C) portals.
In the three volumes of the IBM WebSphere Portal V4.1 Handbook, we cover
WebSphere Portal Enable and Extend.
The IBM WebSphere Portal V4.1 Handbook will help you to understand the
WebSphere Portal architecture, how to install and configure WebSphere Portal,
how to administer portal pages using WebSphere Portal; it will also discuss the
development of WebSphere Portal portlets and how to use specific WebSphere
Portal applications.
Across the volumes of the IBM WebSphere Portal, you will find step-by-step
examples and scenarios showing ways to rapidly integrate your enterprise
applications into an IBM WebSphere Portal Server environment using
state-of-the-art technologies, such as portlets, and implementing new and
enhanced capabilities incorporated in the current releases of IBM WebSphere
Portal Server offerings, such as access controls and page customization using
themes and skins.
Sunil Hiranniah is a Software Engineer and works for IBM Developer Relations
Technical Support Center in Dallas, USA. He has over five years of experience in
the software industry working within various commercial projects. He has wide
experience with WebSphere Portal, WebSphere Application Server, J2EE and
databases. He has written and published extensively on the WebSphere family of
products.
Roshan Rao is a Senior Consultant with Perficient Inc., with approximately three
years of experience in design and development of object-oriented systems. He
has a degree in Commerce from the University of Mumbai and is currently
pursuing an MS in Computer Science from Maharishi University of Management.
He is an IBM Certified Specialist for WebSphere Application Server and
MQSeries. His key areas of work include Java technologies, portals, messaging
and enterprise application development and integration.
Preface xi
working for DaimlerChrysler Aerospace and managing his own business. His
areas of expertise include Pervasive Computing, Unix, Java 2 Enterprise Edition
(J2EE) programming, and Solution architectures. He is a Red Hat Certified
Engineer (RHCE) and holds a Diplom-Ingenieur degree in Computer Science
from Berufsakademie Ravensburg, Germany.
Stefan Schmitt, Marian Puhl, Ingo Schuster, David S. Faller, WebSphere Portal
Development
IBM Boeblingen
Your efforts will help increase product acceptance and customer satisfaction. As
a bonus, you'll develop a network of contacts in IBM development labs, and
increase your productivity and marketability.
Find out more about the residency program, browse the residency index, and
apply online at:
ibm.com/redbooks/residencies.html
Comments welcome
Your comments are important to us!
Preface xiii
xiv IBM WebSphere Portal V4.1 Handbook Volume 2
1
1.1.1 Portal
A portal, as shown in Figure 1-1, is a Web site that provides end users with a
single point of access to Web-based resources by aggregating those resources
in one place and by requiring that users log in only to the portal itself and not to
each application (portlet) they use. Over the years, portals have evolved to
provide aggregation of content from sources such as rich text, video, and XML
and provide personalized services such as user customization of layout and
content.
1.1.2 Portlet
A portlet is an application that is hosted by the portal. In the Portal example
shown in Figure 1-1, Welcome, Quicklinks, World Clock, and Reminder are some
of the default portlets that come with WebSphere Portal installation. Discussing
some of portlet features:
A portlet is a pluggable component that represents an application.
From a developer’s perspective, a portlet is a Java client that runs on the
server.
A portlet provides output to the user by generating markup output that is
assembled into a portal page by the portal.
A portlet manages the user's preferences for the associated application.
PortletConfig
The portlet container relies on the J2EE architecture implemented by
WebSphere Application Server. As a result, portlets are packaged in WAR files
similar to J2EE Web applications and are deployed like servlets. Like other
servlets, a portlet is defined to the application server using a Web application
deployment descriptor, Web.xml.
PortletSettings
In addition to the Web.xml file, the portlet WAR file must also contain a portlet
deployment descriptor, Portlet.xml.
PortletData
A concrete portlet is placed on a portal page by a user or an administrator. This
creates a concrete portlet instance, which is a concrete portlet parameterized
(associated with) a single PortletData object. There can be many concrete portlet
instances per concrete portlet. The PortletData object stores persistent
information for a portlet on a page. This information cannot be changed by an
administrator; it may only be written by the portlet itself. For example, a stock
quotes portlet may have an edit page where a user can specify a list of stock
symbols to include in the list of quotes. The portlet saves this information in the
PortletData object associated with the concrete portlet instance. The scope of
PortletSession
The PortletSession object is a subclass of HttpSession. When a user accesses a
page that contains a portlet, a user portlet instance is created. A user portlet
instance is a concrete portlet instance parameterized by a single PortletSession.
There can be many user portlet instances per concrete portlet instance. The
PortletSession stores transient information related to a single use of the portlet.
PortletRequest
The PortletRequest object is a subclass of the HttpServletRequest. It provides
access to attributes (name/value pairs associated with the request), parameters
from the URI query string, and other control structures such as the Client,
PortletData, and PortletSession objects.
PortletResponse
The PortletResponse is a subclass of the HttpServletResponse. It encapsulates
information to be returned from the server to the client. It can be used by the
portlet to return portlet output using a Java PrintWriter. It provides methods for
creating portlet URIs and qualifying portlet markup with the portlet's namespace.
View
When a portlet is initially constructed on the portal page, it is displayed in its View
mode. All portlet's must support view mode. This is the portlet's normal mode of
operation.
Help
If Help mode is supported, the portlet provides a help page for user's to obtain
more information about the portlet. Help mode is accessed through the question
mark ("?") icon on the portlet's title bar.
Configure
If Configure mode is supported, the portlet provides a page for portal
administrators to configure a portlet for a user or a group of users. Configure
mode is accessed through a wrench icon on the portlet's title bar.
Normal
When a portlet is initially constructed on the portal page, it is displayed in its
normal state, arranged on the page along with other portlets.
Maximized
When a portlet is maximized, it is displayed in the entire body of the portal,
replacing the view of other portlets.
Minimized
When a portlet is minimized, only the portlet title bar is displayed on the portal
Page.
In this section of the chapter, we will show how you can develop and deploy a
simple My HelloWorld portlet.
The Web-INF directory may additionally contain Tag library descriptor files (TLD),
used for custom JSP tags. The jar utility shipped with Java SDK can be used to
create a WAR file. The only difference between a regular JAR file and a WAR is
the directory structure. So, you can simply change to the document root of your
Web archive structure and issue the proper command.
Note: Make sure you use the JDK that comes with WebSphere Application
Server.
Once the Java source is compiled, you can create a JAR file in the Web-INF
directory. For this portlet development, only one class file will be used and we will
not be packaging it as a JAR file.
<servlet-mapping id="ServletMapping_1_1">
<servlet-name>HelloPortlet</servlet-name>
<url-pattern>/HelloPortlet/*</url-pattern>
</servlet-mapping>
</Web-app>
The important aspect of this descriptor is the id attribute of the servlet tag that
would be used to map the servlet definition to a portlet definition in a portlet
application.
<concrete-portlet-app uid="samplepkg.HelloWorld.concrete">
<portlet-app-name>Hello World Concrete app(Sample code)</portlet-app-name>
<concrete-portlet href="#Portlet_1_1">
<portlet-name>My HelloWorld portlet</portlet-name>
<default-locale>en</default-locale>
<!-- Begin translation: -->
<language locale="en">
<title>My simple helloworld</title>
<title-short>helloworld</title-short>
<description>Example portlet that explains how to write simple hello
world</description>
<keywords>hello</keywords>
</language>
<!-- End translation: -->
</concrete-portlet>
</concrete-portlet-app>
</portlet-app-def>
You must obtain the Portal Toolkit from CD 3-3 and install it in WebSphere
Studio Application Developer before trying to write a portlet.
<portlet-app-def>
A required, top level element that contains information about the portlet
application. This element includes exactly one <portlet-app> element and one or
more <concrete-portlet-app> elements.
<markup name="name">
At least one is required. This indicates the type of markup this portlet supports.
Name can have one of the following values: html, wml, chtml. The markup tag
can have the sub-elements <view/> (required), <edit/>, <help/> and
<configure/>. These tags indicate the modes that the portlet supports.
<concrete-portlet-app uid="uid">
A concrete portlet application contains at least one portlet from the portlet
application, but it is not required to contain all of them. The following are
sub-elements of <concrete-portlet-app>.
<context-param>
Optional. This contains a pair of <param-name> and <param-value> elements
that this concrete portlet application can accept as input parameters. A concrete
portlet application can accept any number of context parameters. Administrators
can change the context parameters when they configure the concrete portlet
application. Provide help information using XML comments to explain what
values the portlet application can accept. The unique configuration settings for a
concrete portlet application make up its PortletApplicationSettings.
Note: In this example, we have used the user name wpsadmin and password
wpsadmin.
2. Once you successfully log in, you will see the Portal Welcome Page. On the
top left-hand corner of the welcome page, select Portal Administration.
Portlets Page will be the default. Select Install Portlets portlet as shown in
Figure 1-3 and browse for myhello.war. Click Next.
3. Check for the portlets that will be installed as shown in Figure 1-4. You can
verify based on your portlet.xml description. Click Install.
Tip: The name of the log file can be determined with the append of latest
time and date stamp on it. (for example, wps_2002.07.27-11.00.47.log)
5. Before you can add a portlet to a portal, you need to determine where to put it
in the portal. Portal server has the concept of places (WebSphere Portal
Extend version) and pages (WebSphere Portal Enable version). Users
navigate through the portal by accessing different places, and then selecting
pages within each place. Places can be managed as a unit and you can
change the order of places within the portal. Pages are added to places.
When defining a page, you identify the layout (rows and columns) for the
page. After a portlet is installed, to use the portlet, you must add it to a page.
Figure 1-5 Search for the Portlet that was installed for adding to the Portal page
8. You can add the My HelloWorld portlet to any part of the Welcome Page.
Select the My HelloWorld portlet and click the Add button on the left or right
column of the page. We will add it to the left column of the page as shown in
Figure 1-6. Click Activate to activate the page with the changes.
9. After clicking Activate, your window must show Deactivate before choosing
the Home option. To test how this portlet looks, select Home from the top
left-hand drop-down option; you can see the Welcome Page with your added
portlet as shown in Figure 1-7.
You have successfully developed, packaged and deployed your first portlet.
The typical tasks to perform using the portal configuration interface are:
Backing up and/or restoring entire portal configurations.
XML Access is a command line utility which is available as a Java interface that
ships with WebSphere Portal. This utility is a small HTTP client to portal server
that can also be copied from the machine where WebSphere Portal is installed to
another machine, and run to update portal configuration. When the XML request
has been processed on the server, the resulting XML output is sent back to the
client and written to the standard output, which can be redirected to an XML file.
The XML Access tool can be invoked by running PortalServer\bin\xmlaccess.bat
file and syntax as follows:
xmlacccess <XML file> <userid:password> <portal config URL>
Where XML file is XML request file name
userid and password should be the user ID and password of the portal user
with manage rights on any portal
portal config URL consists of host name, base URI appended with /config
</portal>
</request>
Here are the matching rules between elements of the request XML file and those
of the portlet.xml:
The <package> element's globalid attribute should be the same as the
<portlet-app> element's uid attribute specified in portlet.xml.
The <application> element's globalid attribute should be same as the
<concrete-portlet-app> element's uid attribute specified in portlet.xml.
The <portlet> element's name attribute should be the same as the contents of
the <portlet-name> element specified in portlet.xml.
XML Access opens an URL connection to a servlet that serves the Webpath
/wps/config and sends the input.xml to the servlet. The servlet verifies the validity
of the XML file and updates the portal server. The output of the command itself is
XML data that follows the same schema specified in the input.xml. Once you
have installed the portlet, you can follow the same steps as described in Step 5
of the Installing portlets using Portal administration portlet section.
Companies can also create their own portlets or select from a catalog of portlets
created by IBM and IBM business partners. You can find this information at:
http://www-3.ibm.com/software/webservers/portal/library/
PortletDevelopmentGuide.doc
2.1.1 Definitions
You will need to know some of the basic definitions before you start working with
Portal administration pages.
Portlet
From a portal administrator's point of view, a portlet is a content container to
which users can subscribe. WebSphere Portal administration functionality is
delivered via portlets.
Page
A page is a collection of portlets and containers. A page contains one or more
portlets and containers.
2.1.2 Organization
Portlets are laid out on pages. The Portal administration pages use a Portlet
Selector portlet to provide menu-like access to portlets on the page.
Page groups can have specific access control applied to them. In most cases,
only Portal administrators or sub-administrators will have access to the Portal
Administration page.
Important: Before you start working on Portal administration, make sure that
you have successfully installed WebSphere Portal and you have the
information of a user who has administrative privileges to log in.
Note:
The default user with administrative privilege is generally wpsadmin.
In our example, we will login with the user wpsadmin and password
wpsadmin.
You can also login to the default portal page
http://completedomainname/wps/portal and click the login icon (key
symbol) provided on then right-hand side of the page.
2. If you have successfully logged in, you should see the WebSphere Portal
Welcome Page as shown in Figure 2-2. On the top left-hand side as shown in
the image, select Portal Administration page from the drop down list.
3. WebSphere Portal Administration page will open and you should see a
window as shown in Figure 2-3.
Note: If you get the error message There are no Portlets available on
this page, refer to the redbook IBM WebSphere Portal V4.1 Handbook
Volume 1, SG24-6883, chapter 5, for installation tips.
There is also a Help icon (?) on individual Administration Portlets and clicking
this icon will get you the product information specific to that particular portlet.
Navigation: at any time, you can select any of the administrative portlets by
selecting the appropriate tabs on the Portal Administration page.
2.2 Portlets
The Portlets Page contains the following portlets:
Install Portlets
Manage Portlet Applications
Manage Portlets
Web Clipping
Web Services
Manage Web Services
Note: For this section, we have used the readparameters.war file. We will
walk and explain different portal administration capabilities using this war file.
You can refer to Appendix A., “WebSphere Portal Administration sample code”
on page 197 for the code. You can package the capabilities as WAR files and
save them in a directory on your machine, then install. This is just an example
we have used, and users can incorporate administration functionality for their
own code.
Important: This WAR file for installing the portlet application should be in the
local directory. The portal administrator should be installing the portlet
application on the same machine as that of the portal server. Installing the
portlet from a remote machine will fail.
Figure 2-4 Browse for the WAR file for installing your portlet
2. Check for the list of the Portlets included in the WAR file as shown in
Figure 2-5. In our example, Read Concrete Portlet 1 is selected for
installation. Click Install to begin the installation. You can click Cancel
anytime to stop the installation process.
Tip: If portlet installation is a failure, check for the portal server logs directory
and check for the latest log file located under \WebSphere\PortalServer\logs\.
The name of the log file can be determined with the append of the latest time
and date stamp on it (for example, wps_2002.07.27-11.00.47.log).
We have successfully installed the Read Concrete portlet. We will add this
portlet into a page following the steps as explained in 1.3.2, “Portlet
development steps” on page 8. Once we add it, we should see the page with
the Read Concrete portlet as shown in Figure 2-7. The portlet is designed to
display the context and config parameters.
Select the Manage Portlet Applications portlet and with the Web module
readparameters.war file as shown in Figure 2-8, you can:
Show Info
Update
Uninstall
Web modules can contain one or more portlet applications, servlets JSP files and
other files and are defined in the Web descriptor file (Web.xml).
Portal applications can contain one or more portlets. They are created implicitly
when the WAR file is deployed and they are packaged as an enterprise
application (ear file). You will see the default Web modules in the following figure.
These are installed during WebSphere Portal installation.
Update
The Update option helps you to modify your existing portlet application without
uninstalling your existing portlet application.
Figure 2-10 Browse for the war file for updating your portlet
Let us check the changes made to our portlet after using this Update
functionality. Go back to the drop-down menu on the top-left hand corner of the
page and select your page where you had installed the Read Parameter portlet.
When you bring up that page, you should see the window shown in Figure 2-13.
Tip: It is not required for you to add the portlet again to the page after doing an
Update. Changes are incorporated to the page where the portlet was installed
automatically.
Note: Compare Figure 2-13 with Figure 2-7 and you will see that one more
configparam value is added to the portlet.
Uninstall
The Uninstall option helps to uninstall your existing portlet application.
1. Highlight the Web module (updatesetparams.war) to uninstall.
A confirmation window will prompt for confirmation. Click OK if you want to
uninstall or click Cancel to return.
2. You will return to the Manage Application Portlet and on the bottom of the
Portlet, you can read the message The Web module was uninstalled
successfully and will be removed from the Web module section and the
page where the portlet would have been deployed.
Important: If you do not select any portlet application, a window will prompt
you to choose before you proceed.
Tip: Once you deactivate your portlet application, all the portlets that are part
of the deactivated application will disappear from your customized portal
page.
Rename
You can rename a concrete portlet application.
Purpose: When you clone a portlet application, you may wish to rename one of
the portlet application to avoid duplicate names. The Rename option helps with
this functionality.
1. Highlight the portlet application corresponding to updatesetparams.war.
Select Rename.
A pop-up window will open asking you to provide a new name.
Copy (Cloning)
This option helps to copy your concrete portlet application.
You can activate or deactivate based upon your requirements. When you copy a
Portal application, the newly created application is active by default. However,
portlets that are part of the newly created Portal application are inactive. To
customize this Portal application, you will have to activate it, which will be shown
in the Manage Portlets portlet.
1. Highlight the portlet application corresponding to updatesetparams.war.
Select Copy. A window will prompt you to enter the name for the copy and
click OK. You can hit Cancel to avoid copying.
3. You should see the new copied concrete portlet application, Test for cloning.
Note: Compare Figure 9-16 and Figure 9-17 and you will notice a difference.
You will find a new portlet application for the updatedsetparams.war Web
module.
Modify Parameters
The Modify Parameters option allows you to modify the configuration parameters
of the portlet application. Parameters are originally set by portlet.xml for that
instance.
1. Highlight the portlet application (updatedsetparams.war) you want to modify.
Select Modify parameters.
3. To add a new parameter and value, enter the new values. We will change the
contextparam value (change app1 to app2).
Note:
Context param is defined at the concrete Portlet application level so that all
concrete portlets that are part of that application can access
getportletsetting().getportletapplicationsettings.getattribute.
Config param is defined per concrete portlet, which can only be accessed
from that concrete portlet and using getportletsettings.getattribute.
4. Click Add. Select Save. The parameter and value are saved.
5. Once when you have made the changes or added a new parameter value,
you can delete and close the window if no modifications are required.
6. Select Close to return to the Manage Portlets page.
Tip: The character limit and character type are dependent on the database
setup you have. Generally, the parameter name can be up to 64 characters
and the value can be up to 255 characters. Both can contain letters, numbers,
or other characters.
Show Info
This option shows information for each concrete portlet application. It displays
the names of the concrete portlets that are part of the selected portlet
application.
1. Select the concrete portlet application corresponding to the Web module (the
portlet application in our example: this is a test for you to see the change) and
click Show Info.
Delete
This option deletes the Portlet Application.
1. Select the portlet application that you wish to delete. Click the Delete(X)
button.
2. A prompt window will appear to confirm. Click OK or Cancel, depending on
your requirement.
3. If the deletion was successful, you will not see the portlet application under
the Manage Portlet Applications portlet.
Note: When you use the default of displaying all Portlets, the other selection
options are greyed out.
Figure 2-22 Activate portlets that part of the newly created portlet application
2. Once you select the Activate/Deactivate option, the page will refresh and you
should see the portlet Read Parameters Concrete Portlet 1_Test as Active.
Rename
You can rename your portlet.
1. Highlight Read Parameters Concrete Portlet 1.
2. Click the Rename option.
3. A pop-up window will appear asking you to provide a new name.
Copy
This option copies a portlet.
1. Highlight the Hello Reader portlet.
2. Click the Copy option.
3. You will be prompted with a window asking for a name for the portlet after it is
copied. In this case, we have used Hello Reader 25. Click OK to continue or
Cancel to return.
4. Once the portlet is copied, the Manage Portlet page is refreshed and you will
see Hello Reader 25 portlet as shown in Figure 2-24 with an Inactive
state. You can click Activate/Deactivate to activate this newly created portlet.
Modify Parameters
Modify Parameters allows you to modify the parameter values of your portlet.
1. Select the Hello Reader portlet.
2. Click Modify parameters.
3. You will see a window as shown in Figure 2-25 with portlet configuration
parameters and titles. Select the parameter that requires editing. Enter the
new parameter or value. We have modified the values for configParam1 and
configParam2.
4. Add new parameters as you wish and click the Add button.
5. Edit Locale Specific Titles will help you change your Portlet Title. Select the
Title radio button and click Set title for selected locale.
6. A new window will open as shown in Figure 2-26. Click OK and you will return
to the Portlet configure parameter and title page.
Note: Changing the title option is not mandatory. It can be done based on
individual requirements.
Show Info
This option shows the portlet name, portlet title, and portlet description.
1. Highlight the Hello Reader portlet.
2. Click Show info.
You should see a window as shown Figure 2-28 with the portlet information
for the selected portlet.
3. Click Done to return to Manage Portlets.
Delete
You can delete any portlet.
1. Select Hello Reader 25.
2. Click Delete(X).
3. You will get a pop-up window for confirmation. Click OK to confirm and
Cancel to return.
4. The Manage Portlets page is refreshed and Hello Reader 25 is deleted.
The Web Clipping Portlet uses Transcoding Technology, which allows the
administrator to use the front-end user-interface; it provides the ability to create
new portlets and to wrap contents by specifying particular URL information. It
allows you to identify and extract specific portions of an HTML document as
desired by the administrator. Links have been rewritten to go through the Portal.
2. You will be taken to the next window, Add a Clipper, as shown in Figure 2-30.
Note:
Sometimes JSP pages take time to compile and wait for the page to load.
In the example for this chapter, we have not used any of these Modify
options.
4. Click Next and you should see a window as shown in Figure 2-31. By pointing
and clicking the content, choose the content you would like to clip. Select the
Preview option in the top-right hand corner to open or update the Web
Clipping Preview window with a preview of the content for your Web clipper.
When you are satisfied with the content of your Web clipper, select Next. If
you want to make some changes, you can select Clear. Cancel will take you
back to Add Clipper Portlet.
5. You will see the Content Preview window as shown in Figure 2-32.
This is the content that will appear in the portlet based on your current
settings. Click Done to proceed or Cancel to re-select the contents for
clipping.
6. You should see Handbook Clippers being added to the list of Web Clippers in
the Web Clipper Portlet, as shown in Figure 2-33.
7. To test whether this Handbook Clipper Portlet works, add this portlet to the
page where you had added the Read Parameter portlet and activate the
portlet to the page. You should see the clipped portlet displayed on your page.
Note: You should see the Handbook Clipper Portlet on the available
portlets list in the Manage Portlets portlet, with a status of Active.
For a more in depth discussion of Web Services and its related technologies, see
Chapter 4, “Web Services” on page 165.
Publishing and using a remote portlet in WebSphere Portal involves making the
portlet available through a UDDI registry. Before you can work with the registry,
you will need a user ID and password to access the registry.
There are several public registries available. Access the following URLs to learn
about some of these registries.
Microsoft: http://uddi.microsoft.com/default.aspx
HP: http://hpmiddleware.com/SaISAPI.dll/SaServletEngine.class/
products/hp_web_services/registry/default.jsp
In this section, we will explore administering Portal Web Services using one of
the public registries.
The Portal Administration -> Portlets -> Manage Web Services task is used to
define UDDI registries to WebSphere Portal.
1. Select Manage Web Services Portlet and you should see a window as
shown in the Figure 2-35.
– Click the Add button to add UDDI registry information.
– The Edit option will allow you to edit registry information.
– Using the Delete option, you can delete the UDDI Web Service registry
information.
2. If you click Add, you should see a window requesting registry information, as
shown in Figure 2-35.
When defining the registry to WebSphere Portal, you need to know three things
about the registry:
Inquiry URL
Publish URL
Model Key
The corresponding values for the IBM UDDI Test Registry information that we
have used in our example are:
Display name for Registry: IBM UDDI Test Registry
Registry inquiry URL: http://dwuddi.austin.ibm.com/uddisoap/inquiryapi
Registry publish URL: http://dwuddi.austin.ibm.com/uddisoap/publishapi
Model Key: UUID:UUID:30151A70-0D6F-4651-B578-1AE609AA147C
Note:
The URLs values should be found in the documentation for the registry.
You can find the correct Model Key to use by searching the registry for the
desired service type.
For example, searching for technical models in the IBM Test Registry using
the “rpws” search string yields the entry for
com.ibm.Websphere.portal.rpws.
3. Once you furnish the URL information and the key, click OK to register or
Cancel to return.
4. If you click OK, you should see IBM UDDI Test Registry added to UDDI Web
Services registries in the Manage Web Services portlet.
Tip: The Manage Web Services businesses and the Publish Portlets option
automatically connect to the first registry in its registry selection list when the
task is opened. To access a different registry, just select it from the drop-down
list. The connection is automatically refreshed to the newly selected registry.
Tip: Use the radio buttons to list all portlets or filter the list of portlets by a
string. Do not include wildcard characters in the filter.
7. You should see the Welcome Portlet in your Portlet to be published list. Click
Publish.
8. If the portlet is published successfully, you should see the message Portlets
Published Successfully as shown in Figure 2-39.
9. To remove a portlet from the registry, use the Unpublish portlets task on the
Web Services task page.
10.The Integrate a Web Service as a remote portlet task is used to locate and
bind a remote portlet to your local portal server. Once you define a UDDI
registry to your portal, you can query the registry to determine what services
exist. Any service using the RPWS service type can be accessed as a remote
portlet.
11.Select Integrate a Web Service as a remote portlet option. You should see a
window open as shown in Figure 2-40.
12.You have two options when searching for portlets in the selected registry:
– Use the List all portlets option if the number of published portlets in the
registry is not large.
– If there is a large number of published portlets, you should use the List
portlets within business option. Before you click the Get businesses
link, you may want to refine the list of businesses returned by entering a
string in the Business name contains field. From the list of businesses
returned, select one from the list.
In our example, we will select IBM UDDI Test Registry, Get Businesses
Sunil. Once you have finished entering your filter criteria, click Get portlets
to retrieve the list of portlets. Select Welcome Portlet and then click OK to
integrate a Web service as a remote portlet or Cancel to return.
13.If successful, you should see a message as shown in the Figure 2-41.
14.After a remote portlet has been intergrated, you can access the portlet in all
the same ways you would access a locally installed portlet, for instance, you
can add it to pages, assign access control, choose skins, etc. The name of a
remote portlet is prefixed with the string IBM_Proxy. In our example, you can
find the remote portlet as IBM_ProxyPortlet_Welcome Portlet.
Note:
You can also remove a remote portlet through the Uninstall option under
Portal Administration -> Portlets -> Manage Portlet Applications.
For more information on Web Services, see Chapter 4, “Web Services” on
page 165.
When you select the Global Settings Portlet, you will see a window as shown in
Figure 2-42.
Navigation refers to the way in which the user gets around on the site. There are
several themes that demonstrate some of the different navigation models.
Decorations are the icons and images that are used to provide function and
content links as well as a general look-and-feel enhancement.
Each place has a theme associated with it, and each theme has a set of skins
associated with it.
Themes
A theme is an attribute of a page group, meaning you create page groups and
then apply a theme to it. Themes are not user-specific. All users see the same
theme that is applied to the page group. This means that a user could be
presented with a completely different site experience when navigating from one
page group to the next.
An example directory structure where you can find your default themes in
WebSphere Portal (\WebSphere\PortalServer\app\wps.ear\wps.war\themes) is
shown in Figure 2-43.
Skins
Skins are used to apply specific decorations to portlets. They are used in
conjunction with the theme in order to accomplish this. For instance, the theme's
Cascading Style Sheet is used to specify the color of the portlet's title bar. Some
skins use images to produce rounded corners on the title bar. The rounded
corner images are stored with the different themes that support the skin. This is
done so that the colors match across all of the components of the portlet's title
bar. The rest of the skin assets are generic and apply to all theme uses, so they
are kept in the skins folder.
Skins contain images that are used to create the visual effects of the portlet. The
visual portlet container (lines, shadows, backgrounds, etc.) and the portlet
navigation icons (edit, help, back, etc.) are the main components of a skin.
Skins are applied to the portlet via a JSP known as Control.jsp. Each skin has its
own version of Control.jsp. It is used to specify the exact implementation of the
skin and can be considered the Portlet container.
The search for skin assets works the same way as the themes search. Using the
<wps:urlFindInSkin> tag, the file system is traversed starting with a specific
country within a locale and working up to the skin default.
Skin: A skin defines the frame around a portlet, thus determining the look of
the portlet. It affects only portlets. You can select a skin for each portlet in a
page if the theme has skins associated with it.
A default theme is not required for the portal, but specifying a default skin is
mandatory.
While a default theme is not required for the portal, specification of a default skin
is mandatory.
To create a new skin, make a copy of one of the existing ones and modify the
images and the JSP in order to get the desired look and feel. Once you finish,
you will be able to choose it from the administration portlets.
2. In the Manage Themes and Skins portlet, you will notice that for our example
we have WebSphere as portal default theme and Outline as portal default
skin.
3. Themes have four administrative capabilities:
– Add New theme
– Edit Theme
– Delete Theme
– Set as Default
3. Enter the name for the theme (default locale title). In our example, we have
entered Testing Theme.
4. Enter the directory location of your theme. You can specify just the relative
path.
Note: We will use MyTheme which we created for adding to the portlet.
5. You will have all skins to your left-hand side and you can use the arrow button
and choose the skin that you want for the theme.
Note: If only one skin is chosen, it is selected as the default. However, you
can choose multiple skins and click Set as Default for making a skin the
default skin.
6. You can confirm with the message at the bottom on your default skin. In our
example, we have chose NoSkin as the default skin for our theme.
Edit Theme
The Edit Theme option will help you modify which skin your theme uses.
1. Select the Theme for which you need to modify the skin.
2. Select the Edit theme option.
3. Make the necessary changes. You can also edit local specific titles here.
4. Click OK to confirm the changes or Cancel to return.
Delete Theme
1. Select the theme you want to delete and click the Delete option.
2. A pop-up window will ask you to confirm your deletion.
3. Select OK to confirm or Cancel to return.
Tip:The files that compose the theme are not deleted from the system.
Tip: You should not apply the Admin theme to the portal. This theme is
intended for administrative portlets and renders the portlets without a title
bar.
3. Specify the skin name (NewSkin), default locale and the directory location
where this skin is stored. You can specify just the relative path.
4. Set the Locale-specific Titles option will help you change the locale-specific
titles.
5. Click OK to add the new skin or Cancel to return.
6. You should now see NewSkin added to list of available skins.
Important: The necessary skin files must already exist within a specific
directory path before a theme can be added.
Delete Skin
Perform the following instructions to delete a skin:
1. Select the skin you want to delete.
2. A hint window will pop up, asking you to confirm the deletion. Click OK if you
are sure or Cancel to return.
Important: You should not apply the skin with the name NoSkin to a portlet.
This skin is intended for administrative portlets and renders the portlet without
a title bar.
You can do the following tasks from the Manage Client Portlet.
Note: If the user agent sends Microsoft Internet Explorer 5.5 and
the portal server finds Internet Explorer 5*, then that registry entry is
used to determine the markup sent to the client. For this reason, it is
recommended that you place the most specific User Agent patterns at
the top of the list.
Show Info
Perform the following instructions to show information:
1. Click Select Info and the complete client information for all the clients defined
to WebSphere Portal is displayed.
2. Click OK to return to the client listing.
You will be required to specify the markup name. This is a required field.
The directories of this name also have to be created to support the aggregation
of the portal for clients that support this markup. For example, to add the markup
MathML, the following directories have to be created:
<wps_root>/app/wps.ear/wps.war/MathML
<wps_root>/app/wps.ear/wps.war/windows/MathML
<wps_root>/app/wps.ear/wps.war/themes/MathML
<wps_root>/app/wps.ear/wps.war/skins/MathML
For this reason, avoid characters in the markup name that might cause conflicts
inside file or path names, such as /, \ , . , or & . The markup name also acts as
the default title for those languages where no locale-specific title has been set.
1. Specify the MIME type associated with this markup.
UTF-8 is used as the default character set if the Default character option is
left blank.
2. You can use Set locale-specific settings for specifying/changing markup
settings for different languages. The default markup title is displayed; you can
change this. Click OK to confirm and Cancel to return.
3. Click OK to add the new markup or Cancel to return. Once you click OK, you
should see the new markup with the available markup for WebSphere Portal.
Show info
Perform the following instructions to show information:
1. Select Markup Info to get complete details about all the available markups to
WebSphere Portal along with the date created and last modified information.
2. Click OK to return to the Manage Markups portlet.
The search service can search the portal’s document repository as well as
Internet content. The portal server’s built-in search engine is optimized for
The search engine supports free-text queries, with query assistance and query
word completion. Search queries use advanced query operators (+ or -) to
indicate keywords that must be in the document or keywords that must not be in
the document. The search engine can search documents in any language, and
also supports synonyms and stop word lists. Search results include document
summarization and search results clustering.
To prepare for searching, the search engine builds a full-text index in order to
search documents that are stored in the local file system. The indexer supports
multi-word indexing for high precision. The index can be compressed, and the
size can be controlled for situations where the size of the index needs to be
limited.
Select the Portal Administration -> Portal Settings and Manage Search
Index portlet, and you should see a window as shown in Figure 2-49. It has two
options, Configure search index and Manage search index.
2. Specify the index that the user will select in the search portlet. More than one
index can be created. The location you specify for the search index becomes
the name of the search index. Use this index name when you configure the
search portlet.
3. Specify the location of the index. This is the location where index files are
located on your system.
2. Select the index you wish to create from the drop-down selection list.
3. Click Begin index update to initiate creation of the index. The crawler used
to construct the search index processes asynchronously.
– The Last updated completed at field is updated with date and time
information when a new index has been created or an existing index
refreshed.
– Number of active documents indicates the number of documents retrieved
and indexed.
Note: Depending on the index size, this process can take several minutes
to complete. You can click the browser refresh button to see if the update
has completed, or continue elsewhere in the portal and return to this task
later on to see if the update has completed.
Enable Tracing
The Enable Tracing portlet lists all WebSphere Portal Trace Loggers and allows
you to enable or disable each Trace Logger listed.
1. Click the check box (Trace On) next to a Trace Logger name to enable that
Logger.
2. Select the Save option at the top or bottom of the window to save the Logger
settings.
Tip: Use Enable Tracing portlet to set logging options for the current portal
session only.
Users and Groups: The main goal of Users and Groups is to help the
administrator create portal users and groups without using the LDAP interface
directly.
The user registration page shipped with WebSphere Portal exposes a limited set
of user attributes. You can add or delete attributes as required for your portal
implementation, either by exposing additional attributes from the underlying user
repository (LDAP) that are not currently exposed, or by extending the user profile
to include new attributes.
Portal will recognize an existing user/group in existing repository (LDAP).
A user can modify his profile (except the user ID).
Users may belong to multiple groups.
Note: Using an LDAP directory as a user database, grouping users will not
lead to branches in the LDAP directory. By default, all users go to the
cn=users branch and all groups to the cn=groups branch. The groups will hold
the information of the users via the uniqueUsers field. See also 5.2.4,
“Secureway LDAP” in the IBM Redbook IBM WebSphere Portal V4.1
Handbook Volume 1, SG24-6883 for information on setting up the LDAP
structure during install time.
ii. Provide password information for the user and confirm the password.
iii. Type the first and last name for the user.
iv. Specify the e-mail ID.
v. You can select the preferred language for the user from the drop-down
menu list. If no language is selected, Portal will assume that the user
will use the default language.
Either of these ways create a valid new user that is part of no group and has
therefore the minimum default set of permissions.
On the left-hand side of the Manage users portlet, you will see the option Search
for users.
1. Type the text for search in the Name is field. You can use the asterisk
character, *, as a wildcard.
2. You can type a group name in the Restrict to Group option if you want to
restrict the search to a particular group. If the field is left blank, all groups are
searched.
3. Click Get users. The page will refresh and the list of users will be populated
and displayed.
Show ID
This shows you the ID of a highlighted user.
1. Search for the user you want to view.
2. Highlight the user's name in Users.
3. Click Show ID to display a box with the user's ID information.
4. Click OK when the ID is shown in the pop-up window.
Note: You will not see the inherited permissions of a group in the Access
Control List Administration Portlet in WebSphere Portal Version 4.1.2, but if
you add a user to this group, the user will show the inherited permissions.
The Manage User Groups portlet provides you with tools to help you search for
and assign users to your groups. The following options are available with this
portlet:
Create Group
Membership
Delete group
Show ID
Search for groups
Create Group
By default, there are two different possibilities for creating a group:
Add the group directly to the appropriate branch in the LDAP directory. To do
this, use the Administration Interface of your LDAP directory or create an
appropriate LDIF file and import it to your LDAP directory.
Use the WebSphere Portal User and Groups Administration Portlet. To do
this, use the following instructions:
a. Go to Users and Groups page and select Manage User Groups by
clicking the right tab of the lower tabbed buttons.
Note: The group name must be less than 256 alphanumeric characters.
It can contain alphanumeric characters and the hyphen, -, period, ., and
underscore, _ characters. No other characters are permitted in this
field.
c. Click the plus symbol or Create new group button on the right side of the
window.
d. You will see a message stating that the group was successfully created, as
shown in Figure 2-57.
e. Test: open your LDAP and you should be able to see this new group
added.
Note: For the Restrict to Group field, you can also use a wild card
search using an asterisk (*). An asterisk on its own will, however,
restrict you to users that are members of any group. This means that it
will not list the users that are not members of any group yet.
d. Click the image icon Go to submit your search request and display the
result in the Search Results list.
e. Select the appropriate user from the search results list and click the Add
to group button.
f. The page will refresh and you can see the user listed under the group you
chose earlier.
g. Click the OK button to make the changes persistent and to switch back to
the previous window or add more users to this group. Click Cancel to
return.
Show ID
This shows you the ID of a highlighted group.
1. Search for the user group you want to view.
2. Highlight the user group in User Groups.
3. Click Show ID to display a box with the group's ID information.
2.5 Security
The Security portlet will help you to assign permissions for groups, portlets,
places, pages, Web modules for a group or user and will also help you select a
security vault management task.
Portal has five types of permissions: view, edit, manage, create, and delegate.
The meaning of each permission type with respect to the resource can vary
based on what is meaningful for the type of resource. For instance, view access
for a portlet, page, and place allows the user to “see” the portlet, page, and place
in the appropriate context within the portal. For other resource types, such as
user and user group, view access is not applicable.
1. Select Security Portlet from the Portal Administration page and you should
see a window as shown in Figure 2-60.
The Access Control List portlet allows you to configure access to portal
resources by granting permissions to users and groups.The Access Control
List portlet also passes control of resources to and from external security
mechanisms if desired.
Before a portal can be deployed, the access control associated with portal
resources must be established. When setting up access control, it is
important to remember that permission to a “higher level” resource does not
imply the same permission to a “lower level” resource. For example, access
permission to a page does not automatically grant access to the portlets
contained on that page.
Giving a user or a group of users Manage authority on the object “Portal”
effectively makes them administrators.
The Access Control List portlet allows you to configure access to pages,
places, portlets, etc. by granting permissions to users and groups.
A vault segment can contain one or more credential slots, which are containers
where portlets store and retrieve a user's credentials. A credential slot contains
only one credential and is linked to a resource in a vault implementation, the
place where the credential secrets are actually stored.
Note: Portlets can (on behalf of a portal user) set and retrieve credentials in
both types of segments. However, they can only create credential slots in
user-managed segments.
Many portlets need to access remote applications that require some form of user
authentication. In order to provide a single sign-on experience, portlets must be
able to store and retrieve user credentials for the back-end application they need
to access. For accessing applications outside the portal’s security realm, the
Portal Server provides a Credential Vault service that portlets can use to store
user ID and password (or other credentials) information.
A portal administrator uses the Portal Administration -> Security -> Credential
Vault task to manage vault segments and slots as shown in Figure 2-61.
Note: For information on using Credential Vault portlet and more information
on Portal Security, refer to Chapter 4. of the IBM Redbook IBM WebSphere
Portal V4.1 Handbook Volume 3, SG24-6921.
The content organizer maintains properties and attributes of content, which can
be searched by the portal’s built-in search service.
The purpose of this portlet is to provide a basic portal (enable version) with small
content management capabilities.
First of all, you will need to have a users and groups tree to assign different
permissions to folders. If you want to create one to understand its capabilities, do
the following:
1. Log in as wpsadmin and open the Portal Administration page group.
2. Create groups called xxxadmins and xxxusers.
3. Make the wpsadmins group a member of the xxxadmins group.
4. Add your non-administrative groups as members of the xxxusers group.
4. In the Show in details field, check the date box and save your change.
5. You will see a message: Content format modified successfully.
6. Click Done.
The annotations could be used for categorizing your content. Figure 2-67 shows
a content file list.
To bookmark content, bookmark files by selecting the file and clicking Add to
bookmarks. You can also click the My bookmarks tab to review your
bookmarks.
Note: If you log off and then log in as a different user, you will see that the
PCO changes were made only for this user.
Note: Most of the concepts covered in this chapter are an extension to Portal
Administration. You can refer to Chapter 2, “WebSphere Portal administration” on
page 25, for basic definitions that will be used in this chapter (such as page, page
group, portlet, portal, etc.) and for additional reading material.
Definitions:
Users can have one or more personalized pages, navigating to each one from
the home page. Pages are arranged into page groups or places. Each page
group can have its own choice of color themes, skins and page layouts. Themes
are used to define the fonts, colors, spacing, and other visual elements; themes
consist of cascading style sheets, JSP files, and images. Skins are decorations
and controls placed around portlets, such as title bars, borders, shadows, etc.
Since the look and feel of each page group can be completely different, page
groups can be used to create multiple virtual portals running on one portal server.
In a page group, each personalized page can have a different set of portlets. The
portlets on a page can be selected by end users or by administrators, depending
on their access rights for the page. Administrators can specify that certain
portlets be required, so that end users cannot remove them or rearrange them.
Pages can also be rearranged to achieve a different navigation order.
All of the functions related to customizing page layouts, page contents, color
themes and skins are found in the pages of the Work with Pages page group.
Using these tools, users can see the arrangement of the page and can move
portlets around easily.
Web designers are responsible for building the look and feel of the portal. They
design the graphics and the layouts that will be used in the portal.
Portal administrators are responsible for controlling user access to the portal.
They can make decisions on which applications and designs are available to
users. They are also responsible for selecting what designs will be applied to the
portal.
Users are able to add applications to their portal, as well as create new portal
pages. They can modify the default layout of the portal page, assuming the portal
administrators have given them the proper permissions to do so.
Containers and container content can be locked, but keep the following ponts
in mind.
– Manage rights are required.
– Locked containers cannot be deleted.
– Locked container content cannot be moved or deleted.
– Containers can be container content of other containers.
Portlets are laid out on pages. All WebSphere Portal functionality (administration,
customization, etc.) is delivered via portlets. The Portal Administration pages use
a Portlet Selector portlet to provide menu-like access to portlets on the page.
When combined with the NoSkin skin, these functions appear to be single
windows served to the user. This technique can be used on any type of page.
World Clock is a portlet with Edit, Help, Minimize and Maximize options. On your
portlet, the options are as follows.
Click the Minimize icon and you can minimize your portlet; click the
Maximize icon to maximize your portlet. For this option to be available, you
will have to include this feature with your portlet code.
The Edit option will allow you to edit your portlet. Changes take effect
immediately. You can see this option based on access permission.
The Help option will take you to information about the portlet. For this option
to be available, you will have to include this feature with your portlet code.
Themes represent the overall look and feel of the portal, including colors and
fonts. They also define the layout of the portal components.
For more information on themes and skins, refer to 2.3.2, “Themes and Skins” on
page 78.
Several default themes are packaged with WebSphere Portal server. These are:
WebSphere
Science
Finance
Engineering
Corporate
Admin
The WebSphere theme is depicted in Figure 3-3 and the Finance theme is
depicted in Figure 3-4.
Notice how the portal changes when a different theme is selected. The
WebSphere theme uses a color scheme based on purple, black and grey, while
the Finance theme’s colors are blue and grey.
The tools to navigate through the portal have also changed. In the top left corner
of the WebSphere theme is a pull-down menu that allows users to select a page
group. The Finance theme uses page tabs labelled Home, Work with Pages, and
Portal Administration to allow the user to navigate through page groups.
Themes are typically built by usability experts and graphical designers who have
expertise in user interface design, HTML and Java Server Pages. The portal
administrator is responsible for importing a theme into the portal and selecting it
as a default. This is done through the portal administrative tools.
3.2.1 Skins
Skins are the look and feel surrounding a portlet. Skins control the frame
surrounding the portlet and the title bar of the portlet. Each portlet can apply a
different skin.
Examples of portlet skins are shown in Figure 3-5, Figure 3-6, Figure 3-7 on
page 134 and Figure 3-8 on page 134. They are examples of outline, shadow,
album and noskin, respectively. The Noskin example shows a portlet without any
borders or title graphics. Notice how this contrasts with the other skins.
Each skin can define the graphics surrounding the outer edge of the portlet. The
shadow skin in Figure 3-4 has created a shadow effect around its borders and
has tapered its top right edge.The album skin shown in Figure 3-5 has created a
dotted edge border with creases at the bottom.
An administrator can also select which skins will be available for a given theme.
The default skin Outline is applied when WebSphere Portal Server is installed.
The Work with Pages page group provides the user with the ability to customize
his/her experience. This includes creating page groups and pages, laying out
portlets on pages, choosing skins, and locking portlets in place on a page. Users
may only be allowed to customize their own experiences, or they may have
access permissions that allow them to make changes that affect others.
Before you sign in to WebSphere Portal, you have the following options on the
top-left hand banner of the page.
Log in to WebSphere portal and you should see a Welcome page. On the
Welcome Page, select the Work with Pages page group from the drop-down
menu list that you see in the top left hand corner as shown in Figure 3-9.
If you select the Work with Pages page group option, you should see a window,
as shown in Figure 3-10.
Figure 3-10 Portlets that comprises work with pages page group
With the Manage Places and Pages portlet, shown in Figure 3-11, you can:
Create or delete a place
Modify the properties for a place (the theme, markup, and locale specific
titles)
Change the ordering of places
Create or delete a page belonging to a place
Modify the properties for a page (the markup and locale-specific titles)
By default, any user in WebSphere Portal will have Create permission for Places
and Pages.
Note: In our example, we have named the place Handbook Place and
have kept the default settings. We shall use this place throughout for an
explanation of customization.
3. Select the theme from the drop-down menu for your place. The selected
theme will appear in the theme preview on the right-hand side of the page.
You can select various themes and, based on the preview, finalize the theme.
Note: You should not apply the theme with the name Admin to a place.
This theme is intended for administrative portlets and renders portlets
without a title bar.
Important: When a place is deleted, pages within that place are also
removed, and any individual user settings made to portlets on those pages are
lost.
Important: This option only appears to a user who has Manage permission
for the entire portal.
Select a place for which you need to create a page and click the Manage Pages
option. You should see a window as shown in Figure 3-14.
Create page
This option will help you create a new page from an existing place. You must
have Create permission to create a page to a place. Using this option, you can
also reference an existing page, apply a layout, select supported markups,
define a list of associated portlets, and specify locale-specific titles.
If you reference an existing page, the page name, layout, supported markups,
locks, skins, portlet list, and locale-specific titles are predetermined by the
3. Select the Create new option. This option will create a new blank page. The
Reference Existing option will inherit all layout, content, locks, titles, markups,
and portlet lists from another page.The option to create a new page that
references an existing page is present only if you have Create permission for
pages, View or greater permission on a place, and Manage and Delegate
permission for a page in a place. In this example, we will use the Create new
option.
4. A page will open as shown in Figure 3-16.
5. Specify the administrative name and default locale title. For this example, we
have specified the page name as ITSOTester.
6. Select a page layout you would like the page to use. The column layout can
be changed later using the Edit layout and content portlet.
7. Specify the supported markup. In our example, we have only HTML as the
option since we had selected HTML as the only markup for our Handbook
Place.
8. Click Set locale-specific titles to specify locale-specific names for the place.
A list of locales appears. Select a locale, then click Set title for selected
locale. A prompt for the title appears. Type in the place name for the selected
locale, then click OK.
Note: This option will appear only if your portal is configured to support
multiple languages.
Figure 3-17 New page added to the list of pages you can manage
Limitation: With the current version, which is used for this book, WebSphere
Portal 4.1.2 cannot add a page into a page, or a place into a place. This
functionality will be offered with the next release of WebSphere Portal.
Delete a Page
This option will allow you to delete a page from a place. When a page is deleted,
layout settings and any individual user settings made to portlets on those pages
are lost. If you delete a page that another page references, both pages are lost.
1. Select the page that you would like to delete.
2. Click the Delete a Page option.
3. You will see a page open with a warning message requesting your
confirmation before the page is deleted.
4. Click OK if you are sure or Cancel to return. If you click OK, this page will be
deleted from the place.
5. Click Done to return to Manage Places and Pages portlet.
3. To change the order of the pages in the place, click Before and After and you
will notice the changes.
4. Click Done to exit this window.
5. If you do not make any changes, the top page will be the default page that
place will display when the user logs in next time.
6. For the current session, the move of these pages is immediate and you can
notice the changes.
Tip:
Each page group can have its own theme.
Each portlet can have its own skin.
1. Select the Work with Pages page group; the Edit Layout and Content portlet
is the default portlet that you see, as shown in Figure 3-20.
2. Select a Place from the drop-down menu available in the Edit Layout and
Content portlet.
3. We will select for this example Handbook Place, which we created earlier.
4. The page will refresh and will provide you with a list of available pages for this
place.
5. Select a page you wish to modify. We will select ITSOTESTER as shown in
Figure 3-21.
6. Once you have selected a page for modification (in our example,
ITSOTESTER), you should see a window open as shown in Figure 3-22.
Note: If specific portlets are already associated with the selected page, the
portlet list will be locked. Only portlets available in the portlet list can be
placed on the selected page.
When you select a page to modify, the page is deactivated to prevent users
from seeing the page as you work on it. The tasks that you perform on the
page, depends on the access permission.
9. Click the Activate icon to activate the page when you have finished, so that
users can access it. You will notice that the page will turn to Deactivate state.
You will notice Welcome Portlet on the left-side of the page and World Clock
portlet on the right-hand side of the page.
Tip: If you open your page and do not see any portlet, make sure that you
have activated the page. For any changes that you make on the page, you
need to click Activate.
Use the icon descriptions as shown in Figure 3-1 as a guide in changing your
layout.
To add a container for example, click Show layout controls. You will see
additional icons as shown in Figure 3-28. The various options as shown in the
figure are as follows.
– A - This option will allow you to add column containers.
– B - Clicking this option will place your entire layout into a separate
container. If the root container is a row, this icon places the existing layout
inside a column, and a new row is created beneath the existing root row. If
the root container is a column, this icon places the existing layout inside a
row, and a new column is created to the right of the existing column.
– C - Clicking this icon will open a pop-up window where you can set column
width for the page. Column width can be set by pixels or by percent.
– D - Moves the column container to right.
– E - Moves the column container to left.
Once you finish making changes to the layout, you can click Hide Layout
Controls. Then click Activate for the changes to take effect.
You can also decide which portlets can or cannot be deleted from the page.
These settings control how a user can work with the page in the Edit Layout and
Content portlet.
You must have Manage access for a page in order to modify the permissions
settings. An end user must have Edit access for a page in order to modify
unlocked containers or container contents.
Select the Set Permissions portlet. You will be asked to select the place and a
page, for which you need to set permissions (see Figure 3-29).
For our example, we will select Handbook Place and the ITSOTESTER page.
You should see a window similar to Figure 3-30.
You will see a check mark next to the portlet on your page. This is the default
setting.
Portlets can be deleted if the Delete icon for the portlet is available for users
who are modifying the page using Edit Layout and Content portlet. This is
when the portlet is check-marked.
Deselect this option, and users using the Edit Layout and Content portlet
cannot delete the portlet since this option will not be available on the portlet.
You need to click the same option again to unlock the container contents. When
the container content is unlocked, a user with Edit access to the derived page
can perform any of the tasks with the contents. The icons for performing these
tasks appear when a user works with this page in the Edit Layout and Content
portlet.
Container locked (C or D)
When a container is locked, it cannot be removed from the page. The Delete icon
for this container is not available when the user works with this page in the Edit
Layout and Content portlet.
Click the icon again to unlock the container. When it is unlocked, it can be
removed from the page. You can see the delete icon when the user tries to edit
the page using Edit Layout and Content portlet.
Changing the skin will change the look and feel of the portlet.The page that the
portlet is on belongs to a place. The place has a theme associated with it. The
theme has a set of skins associated with it. This set of skins is the set from which
you can choose a skin for the portlet.
1. Take a look at Figure 3-25. We will change the skin using Choose Skin portlet
and you can notice the difference.
2. Next to the Portlet, you have a drop-down menu option. Select the skin you
want your portlet to have on the page. Each portlet can have different skins
on a page.
3. Click the eye icon and you can preview the skin.
4. Outline is the default skin applied to the portlet when WebSphere Portal is
installed. For our example, we have changed Welcome Portlet to have
Shadow Skin and World Clock portlet to have Hint Skin.
5. Select your page group and page from the drop-down menu option at the top
of the page and you will see a window as shown in Figure 3-32.
Find Publish
Service Service
Requestor Provider
Bind / Invoke
Figure 4-1 Web Services Publish, Find and Bind
Publish
Publishing and unpublishing involves promoting a service to a registry or
removing those entries. When a service is listed in a UDDI registry, it can be
discovered and subsequently invoked by the service requestor.
Find
The Find operation is performed by service requestors and service brokers
together. The service requestors describe the kinds of services they are looking
for, and the service brokers deliver the results that best match the request.
Bind
The Bind operation takes place between the service requestor and the service
provider. After locating a particular service, the requestor can bind to the service
using the SOAP protocol.
Service requestor
A service requestor uses an API to ask the service broker about the services it
needs. When the service broker returns results, the service requestor can use
those results to bind to a particular service. Those services can be invoked to
create applications.
Service provider
The service provider deploys a service to a UDDI registry that makes those
services available. The functions of a given Web service are described using the
Web Services Description Language (WSDL).
Individual portlets can also use Web Services internally to deliver their
functionality, as seen in Figure 4-2. For example, a search portlet might query the
user for a search string, then use a search Web service to search the Internet; or
a calendar portlet might act as a front end, providing views for a calendar Web
service. WebSphere Studio Application Developer provides development tools
for quickly developing Web Services and for generating proxy classes from
WSDL descriptions. In the case of remote portlets, the portlet is actually running
on a remote server and is accessed via the Portlet Proxy, making it transparent to
the local user. In the case of a local portlet calling a Web service, the portlet is
running locally and the Web service is running remotely also access by a proxy.
The difference is where the portlet itself runs.
Portlet
SOAP/RPI
Inventory
Proxy Portlet
SOAP/RPI SOAP/XML
Portlet Pricing Pricing
Proxy Portlet Service
Local Portal
Search Search
Portlet Service
SOAP/SearchML
Local
Portlet
For remote portlets to be dynamically integrated into a portal, the portlets have to
be provided as a Web service. This requires a Remote Portlet Web Service
(RPWS) interface description in WSDL. The WSDL description defines a
common set of methods for all remote portlets along with the required
parameters and return values for each method. This RPWS description is
produced and placed into the UDDI registry when the WebSphere Portal
administrator publishes the portlet (Figure 4-3).
Since the WSDL describes simply the methods, parameters and return values,
the implementation does not have to be Java. As long as the service described
conforms to the RWPS interface it can be used as a remote portlet.
portlet info
...
portlet info
Find Portlet Publish Portlet
SOAP SOAP
Portal
Portal
Administration
Administration
Portal Portal
Invoke Portlet
Figure 4-3 WebSphere Portal and remote portlets
Once the remote portlet is published to the UDDI registry, a portal administrator
searches the registry for services that implement the RPWS interface and add
them to their portal’s registry. As discussed earlier, a portlet proxy actually gets
registered on the portal registry. Once the portals are in the registry, the user can
add them to their portal Web pages.
When the page that references a remote portlet is rendered by the portal
aggregation, the portal uses the portlet proxy to invoke the remote portlet Web
service via the Remote Portlet Invocation (RMI) protocol (Figure 4-4). The portlet
invokes the portlet proxy the same way it would a local portlet passing portlet
request and portlet response objects.
Servlet
Request
Portlet
Request Portlet
Portal Proxy SOAP
Engine Request Remote Portlet
SOAP
Proxy
SOAP SOAP Wrapper
Response
Portlet
Response
Servlet
Response
The portlet proxy internally invokes the SOAP Proxy that marshals all the
parameters and invokes the SOAP Wrapper. The SOAP Wrapper on the Web
Service side unmarshals the parameters and invokes the Web Service. On return
the response in returned in a SOAP response from the Web Service via the
SOAP Wrapper. The SOAP Wrapper marshals the response and sends a SOAP
response to the SOAP Proxy who in turn unmarshals the response for the portlet
proxy. The portlet proxy finally returns a portlet response in a similar way to how
a local portlet would return a portlet response. The response is then returned by
the portal and the user transparently sees the response from the remote portlet
as if it were a local portlet.
The key to WebSphere Portal remote portlets is the use of the UDDI registry.
WebSphere Portal provides the ability to define portlets as Web Services.
Through the portal user interface, you can access a UDDI registry to:
Publish a portlet as a Web service
Search for a portlet on the registry to add to your portal
In 2.2.5, “Managing Web Services” on page 65, we used the IBM test registry to
publish and locate a portlet Web service. In this section, we install and configure
the IBM WebSphere UDDI registry for use with WebSphere Portal.
Prerequisites
The IBM WebSphere UDDI Registry assumes that the following products are
already installed on the user's system:
DB2 Enterprise Edition 7.2 FP5 or FP6
Important: Please note that if DB2 is not installed in the default location of
C:\Program Files\SQLLIB; you may be required to perform some additional
steps after completing the installation.
A browser:
– Internet Explorer V5.5 with SP2 and security fix Q321232 (these must be
applied in that order), or
– Netscape Navigator 6.1 or later
The IBM WebSphere UDDI Registry will run on the following platforms:
Windows 2000 Advanced Server SP1 or SP2
Windows 2000 Server SP1 or SP2
Windows NT Server 4.0 SP 6a
Red Hat Linux 7.1, 2.4 kernel
SuSE Linux for Intel 7.1, 2.4 kernel
Download the IBM WebSphere UDDI Registry V1.1.1 zip or tar file from:
http://www7b.boulder.ibm.com/wsdd/downloads/UDDIregistry.html.
Preinstallation
Several steps are necessary to ensure a successful install. These steps are as
follows:
1. Ensure that you have upgraded the JDBC drivers for DB2 to the 2.0 level.
Installation of DB2 defaults the JDBC drivers to the 1.0 level. You must
To start the installation of the IBM WebSphere UDDI Registry, do the following:
1. Run the setup program extracted from the UDDI registry download.
2. Click OK in the UDDI Registry Welcome window, as seen in Figure 4-5.
You are asked to accept the licence terms and conditions (Figure 4-6). These
are the licence terms and conditions that you accepted when you obtained
the product; for example, from the download site.
3. Click OK.
5. Next, select either a Custom or a Typical install: the Typical install is the
default.
This installs all the components of the IBM WebSphere UDDI Registry that
you need to use it.
The Custom install allows you to select one or more of the following
components:
– UDDI Registry Files
– UDDI4J
– InfoCenter
– Sample files
7. Next, you are prompted for the database user ID and password as seen in
Figure 4-9.
This user ID is used to create and access the UDDI Registry database, and
should be a user ID with administrative privileges which obeys the rules for
DB2 user IDs.
8. Next, the UDDI registry install sets up and configures the database used by
the registry.
Some of this setup needs the WebSphere Administrative Server to be
running; if it is not, the installation process starts it for you.
The database setup is comprised of the following steps:
a. Create a JDBC provider in your WebSphere Application Server called
UDDI JDBC Driver and an associated data source (UDDI data source). If
you already have a JDBC provider called UDDI JDBC Driver then this,
together with any associated data source, is replaced.
b. Create a database called UDDI20 and populate it with the tables and
standard categorization schemes that are required for the UDDI Registry.
If you already have a database called UDDI20, then this will be replaced
(unless you choose not to Set up UDDI Registry Files, as part of a Custom
install).
Note: the UDDI registry will be installed on the default application server.
10.When the installation has finished, you will see a window asking you if you
want to look at the readme. If you wish to view the readme then select the
box.
11.Click Finish to complete the installation.
After completing the installation, you will be able to see the UDDI Registry
application using the WebSphere Administrative Console, as follows:
1. Start the WebSphere Administrator's Console if it is not already running.
2. In the navigation pane, expand the administrative domain so that you can see
Enterprise Applications, and expand that to show the applications that are
installed. An application called UDDI Registry should be shown, as seen in
Figure 4-15.
You have now successfully installed the WebSphere UDDI Registry. The next
section details the steps necessary for verification.
4.3.2 Verification
In order to use the IBM WebSphere UDDI Registry, start the WebSphere default
server (or stop and restart it if it is already running).
The IVP samples are installed into the same target directory as the other SOAP
samples and they use the same XML files as the basic Java SOAP samples.
SOAPSampleIVPa saves three businesses, six services (two per business) and
three tModels. The data structures are very basic and consist only of a name.
The keys returned by the save_* UDDI API calls are then written to a file,
SOAPSampleIVPa.out. SOAPSampleIVPb then reads in these keys from the file
in order to delete the saved data from the UDDI registry.
Note: Each time you run SOAPSampleIVPa, it overwrites the output file
SOAPSampleIVPa.out so, if you wish to use SOAPSampleIVPb to delete the
data, you must run this before you next run SOAPSampleIVPa.
To run the IVPs, complete the following steps on the same system as the UDDI
Registry:
1. Ensure that DB2 and the WebSphere Admin Server are started.
For SOAP samples to work, you need to ensure that the Client JDK is either
the one shipped with IBM WebSphere Application Server or a later IBM JDK.
– For Windows - ensure that C:\WebSphere\AppServer\Java\bin is present
in the PATH statement before any other JDKs
– For Linux - ensure that /opt/WebSphere/AppServer/Java/bin is present in
the PATH statement before any other JDKs
Note: You must use the IBM WebSphere supplied JDK or a later level of
the IBM JDK.
For Windows, the default system path can be set by clicking Start -> Settings
-> Control Panel -> Settings-> System-> Advanced Properties->
Environment Variables.
UDDI GUI
For the purposes of this example, we will not set up SSL. By default, the
WebSphere UDDI Registry installs such that publishing through the UDDI GUI
requires SSL. To change this we must perform the follwing steps.
1. Open the following file for editing:
<WAS-Root>/installedApps/UDDI_Registry.ear/gui.war/Web-INF/Web.xml
2. Search for the tag <transport-guarantee> and change its content to NONE, for
example:
<transport-guarantee>NONE</transport-guarantee>
3. Make sure both <transport-guarantee> tags are set to NONE.
4. Save the file.
5. Restart the UDDI registry application: locate UDDI Registry, right-click it, stop
and start it.
6. Invoke the registry GUI, click Publish.
You should see a prompt for authentication; use wpsadmin / wpsadmin.
2. Add the UDDI Registry by clicking Add next to the UDDI Web Services
registries list.
3. Next, specify the registry parameters as seen in Figure 4-18.
This completes the configuration of WebSphere Portal for use with the IBM
WebSphere UDDI Registry.
This section walks through the steps to determine the tModel Key to be used with
the UDDI registry.
1. Invoke the UDDI GUI via the URL http://<uddi server>:9080/uddigui.
Note that the UDDI Registry GUI runs by default as a Web Application on the
internal HTTP server, so we must specify port 9080 in the URL.
2. Define a business as seen in Figure 4-20.
We must now specify the name of the service we would like to define and publish
it.
It is the tModel of our service that we must specify in the UDDI registry definition.
Unfortunately, there is no straightforward way to determine the tModel Key. To
find the tModel Key for our service, do the following.
1. From the Publish tab in the UDDI GUI:
a. Click Show owned entities.
b. Scroll down to the Technical Models at the bottom of the page, as seen in
Figure 4-23.
c. To find the tModel Key, you must select the tModel and open it in another
window.
In our case, right-click ITSO Remote Portlets and select Open in New
Window.
d. The URL in the new window contains the tModel Key, as seen in
Figure 4-24.
The tModel Key is the portion of the URL that starts with UUID. In our
example, the tModel Key is
UUID:3A29EC6935-3ECF-4D02-825C-037A05F12AFB.
Note the substring %3A is replaced by a colon, “:”.
import java.util.*;
PrintWriter pw = portletResponse.getWriter();
String s =
portletRequest.getPortletSettings().getApplicationSettings().getAttribute("contextParam");
pw.print("The value of context param <b>contextParam1 </b> is " + s);
s = portletRequest.getPortletSettings().getAttribute("configParam1");
pw.print("<br>The value of config param <b>configParam1</b> is " + s);
}
-----------------------------------------------------------------------------
Select the Additional materials and open the directory that corresponds with
the redbook form number, SG24-6920.
The publications listed in this section are considered particularly suitable for a
more detailed discussion of the topics covered in this redbook.
IBM Redbooks
For information on ordering these publications, see “How to get IBM Redbooks”
on page 207.
Domino and WebSphere Together Second Edition, SG24-5955-01
Deploying Quickplace, SG24-6535-00
Customizing Quickplace, SG24-6000-00
Lotus Discovery Server 2.0: Deployment, Planning, and Integration,
SG24-6575-00
Inside the Lotus Discovery Server, SG24-6252-00
WebSphere Portal Collaborative Components, REDP0319
IBM WebSphere Portal V4.1 Handbook Volume 1, SG24-6883-00
IBM WebSphere Portal V4.1 Handbook Volume 3, SG24-6921-00
IBM WebSphere V4.0 Advanced Edition Handbook, SG24-6176-00
Enterprise Business Portals II with IBM Tivoli Access Manager,
SG24-6885-00
A E
EIP 92
abstract portlet class 3
EJB 179
access control list 111
Enable Tracing 76, 98
Access Control List Administration Portlet 106
Enterprise Information Portal (EIP) 92
Access Control portlet 32
Enterprise Information Portal Search 92
administration portlets 26
assets 79
authentication 111 F
authorization 111 Figure 2-8 36
find operation 167
finding and binding 173
B
bind operation 167
branding 78 G
Bulletin Board 159 Global Settings 76
C H
Cascading Style Sheets (CSS files) 79 help menu icon 31
Choose Skins 162 hierarchy for a portlet class 4
CJK language support 96 HTML 132
client device definitions 22 HTTP 168
Clipping Runtime Portlet 59 HTTPServlet 3
concrete portlet 5 HttpServletRequest 6
concrete portlet application 5 HttpSession 6
Configure Search Index 94
Content Organizer portlet 114, 120
content repository 119
I
IBM Portlet API 8
credential segments and slots 22
IBM Tivoli Access Manager 114
credential vault 113
IBM UDDI Registry 173
customization 126
IBM WebSphere UDDI Registry 175, 187
customization roles 126
images 79, 130
InfoCenter 179
D input request XML file 20
DB2 JDBC Applet Server 175 Install Portlets 32
decorations 78 Installation Verification Program (IVP) 185
deployment descriptors 10 Internet Explorer 174
Directory Management Tool (DMT) 100
Distinguished Name (DN) 109
DMT 100
J
J2EE applications 10
document search 92
JAR file 9
jar utility 9
Java SDK 9
Index 211
Windows 2000 Advanced Server 174
Windows 2000 Server 174
Windows NT Server 174
Work with Pages 22
World Clock 129
World Wide Web Consortium (W3C) 168
WSAD 8
WSDL 168, 170
X
XML 12
XML Access 20–21
XML descriptor file 19
XMLAccess utility 19